home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL96.LZH / t0210 / text0036.txt < prev   
Encoding:
Text File  |  1996-03-07  |  8.3 KB  |  199 lines
  1.  
  2. Subject: re : Best FPS for playable BM
  3.  
  4.  
  5.  >> I was wondering what everyones perception of the minimum frame rate
  6.  >> to make the game playable.
  7.  
  8. Considering how much the Falcon is having to do each frame, I doubt we are 
  9. going to have a great deal of choice what the framerate is going to be. As
  10. long as running it's as fast as the Falcon can cope with, all we can do is
  11. pick a window size / quality setting to suit our preferences. We are
  12. certainly not going to be able to increase the framerate without removing
  13. big chunks of code for things like shading effects and texture mapping.
  14.  
  15.  
  16. Now that the shading effects for floors and walls is working, it's 
  17. unlikely to get much slower (if any), since all of the main drawing
  18. routines are practically finished (This is v1.9, which I will upload very
  19. soon).
  20.  
  21.  
  22. v1.9 _did_ get a _lot_ slower than v1.7 / v1.8, but I have worked hard to 
  23. correct this and it's now quite close to the speed of v1.7. It now uses the
  24. full PC-Doom method for lighting / shading on walls & floors which looks a
  25. lot better. Unfortunately, it's doing a hell of a lot more processing work
  26. now for each pixel drawn.
  27.  
  28.  
  29. The _latest_ situation with v1.9 is that it is _sometimes_ slower than 
  30. v1.7, and it's _sometimes_ faster - especially with a smaller window. I had
  31. to do a lot of optimising and reprogramming of the texturemapping to get
  32. the speed back up, but the new shading system looks a lot better and I
  33. think it was worthwhile. Removing all shading & lighting at this point
  34. would probably make BM very fast indeed - maybe playable at 320x200!
  35.  
  36.  
  37.  > IMO, the minimum frame speed is 7 FPS. But it's not very fun to play,
  38.  
  39. It's only 7FPS when you attempt to play it fullscreen using the top 
  40. quality setting, which I suggested very near the start to be quite an
  41. ambitious target. I expect unaccelerated Falcons to depend on either low
  42. quality settings or a smaller game window or both. 320x200 and similarly
  43. large windows are only going to be useful with accelerated machines, and
  44. even then it will depend on the effectiveness accelerator.
  45.  
  46.   > and perhaps there will be some problems to shoot targets with such a
  47.  > low frame speed... Now, the minimum FUN speed is about 13 FPS. At 15,
  48.  > it's really ok, But
  49.  
  50. In which case (for that particular machine) the best solution is to shrink 
  51. the game-window until you reach the 13fps you wish to achieve. I simply
  52. can't make the program any faster without hacking bits out.
  53.  
  54.  
  55. If I have time, I will implement options to disable depth-cueing and all 
  56. lighting effects, but that would mean 3 different DSP drivers, as it's too
  57. complicated to make these things switchable in one driver. The advantages
  58. of disabling depth-cueing are not great, but they might swing the balance
  59. on some machines. Disabling _all_ lighting effects might as much as double
  60. the framerate, but will look quite grim. The French Doom project currently
  61. uses no lighting effects so this is a good reference point for those
  62. interested - some textures & objects become hard to discern as distance
  63. produces no additional visual cues. The speed might make it a worthwhile
  64. modification...
  65.  
  66.  
  67.  > I think it also depends on the speed you're moving in the game ? I mean
  68.  > that if
  69.  > you're moving at 100 miles/hour, a 15 FPS refresh rate won't be
  70.  > sufficient...
  71.  > But for a normal player, it will be good enough :-)
  72.  
  73. The movement of objects in the game will be scaled using interrupt timers, 
  74. or by placing the kinetics module on a slow interrupt itself - or even by
  75. forcing the mainloop to complete every 1/35 second and only drawing as much
  76. of the screen each pass as there is time to deal with. This means that the
  77. game actually plays at the same rate regardless, but the screen is only
  78. updated as-and-when there is time.
  79.  
  80.  
  81. Movement scaling using interrupts is the easiest way to do this, and using 
  82. the mouse in BM as opposed to the keys will give a good idea of what to
  83. expect when the keys are done the same way.
  84.  
  85.  
  86.  >     I haven't made a real test yet, but I saw quite a big difference,
  87.  > 'playing' BM with or without my accelerator board, though it only
  88.  > boosts the CPU to 32 Mhz. I think the difference's about 3 FPS... Does
  89.  
  90. That sounds about right - or at least it doesn't sound _wrong_ anyway...
  91.  
  92.  > BM make a total use
  93.  > of the DSP for the rendering, in its current state ? I think not, if a
  94.  > CPU-only
  95.  > accelerator board increases the FPS rate. :-|
  96.  
  97. I don't know what you mean by 'total use of the DSP', but what I think you 
  98. are asking is 'exclusive use of the DSP' - to which the answer is no.
  99. However, the DSP is still used to the full at rendering time.
  100.  
  101.  
  102. The DSP is currently doing 90% of the _work_ involved in the texture 
  103. mapping, or in other words - of all the jobs needing done, the DSP does the
  104. largest share by far.
  105.  
  106.  
  107. Since DSPs in general (by their very nature) are separate processors with 
  108. separate memory and no direct access to video or the CPU's bus, the
  109. Falcon's DSP is completely unable to draw anything to the screen without
  110. the CPU's help. At the end of the day, letting the CPU do all of the actual
  111. drawing is actually much quicker than getting the CPU to help the DSP. As I
  112. said, the DSP can't do it on it's own for engineering reasons.
  113.  
  114.  
  115. Now, considering the DSP is doing 90% of the _work_ involved in the 
  116. texturemapping (calculating which pixels come from where), and the CPU is
  117. taking the information _supplied_ by the DSP and using it to do the
  118. remaining 10% of the work (take the pixels out of the texture at the
  119. correct place and draw them on the screen with the relevant lighting
  120. adjustments), then we would obviously expect the DSP to take the largest
  121. portion of the total time - and speeding up the CPU would have little
  122. effect...
  123.  
  124.  
  125. The reason this _doesn't_ happen as expected is that the DSP is _many_ 
  126. _many_ times faster at doing it's much larger job than the CPU is at doing
  127. it's much smaller job. In addition to this, the DSP is doing it's job
  128. _while_ the CPU is doing it's _last_ job - they work in parallel, and
  129. absorb a large quantity of the time from each other's work.
  130.  
  131.  
  132. Put simply, you can't estimate with _any_ accuracy how much BM uses which 
  133. chips to do what, simply because of how many speed-altering factors are
  134. involved.
  135.  
  136.  
  137. Here is a list of things that affect the speed of BM on the Falcon in ways 
  138. not directly attributed or scaled according to clock-rate :-
  139.  
  140.  
  141. Instruction cache
  142. Data cache
  143. CPU bus / CPU cache concurrency
  144. DSP host port latency
  145. DSP 8-bit host port / multiple bus waitstates
  146. DSP / CPU parallelism
  147. Very large DSP / CPU speed difference
  148. CPU reliance on main bus
  149. DSP non-reliance on main bus
  150. Bus arbitration difference between RGB / VGA
  151. Possible 16-bit FastRam
  152. Possible 32-bit FastRam
  153.  
  154. So if you mix this lot up, the result is that any estimates on speed or 
  155. efficiency are miles off, and very probably wrong. I even get my estimates
  156. wrong due to this stuff and I'm supposed to know what's going on in there
  157. more than anyone else!
  158.  
  159.  
  160. :)
  161.  
  162. I have heard at least one person ask if BM takes advantage of FastRam 
  163. properly, as it didn't seem to make a fantastic difference. The reason is
  164. not that FastRam _isn't_ faster, or _isn't_ supported - it's because I
  165. wrote the code to run _faster_ on a normal Falcon than it normally would
  166. -by taking advantage of instruction interleaving, which means each memory
  167. reference can take place simultaneouly alongside several cached CPU
  168. instructions if _great_ care is taken. This is why I was so emphatic (at
  169. the start of the project) that the code must operate out of the cache as
  170. much as possible, even at the expense of increasing the amount of
  171. processing - because if done correctly, you can almost make Falcon ram as
  172. fast as FastRam. It is really fiddly and annoying to write - but as you can
  173. see, something that looks like you are not supporting hardware properly can
  174. turn out to be the exact opposite!
  175.  
  176.  
  177. However, your comments were sensible enough when applied to standard 
  178. Falcon software - it's just that this particular program is stupidly
  179. complicated in the speed dipartment.
  180.  
  181.  
  182. :)
  183.  
  184. Anyway, I'll upload v1.9alpha tonight if I can...
  185.  
  186. Bye!
  187.  
  188. Doug.
  189.  
  190. ┌───────────────────────────────────────────────────────────────────────┐
  191. | Black Scorpion Software / Falcon040 ~ 4MbSRam ~ 16MbFRam ~ Expose ~:) |
  192. ├───────────────────────────────────────────────────────────────────────┤
  193. | Doug Little ~ Neil Stewart ~ Dave Murphy ~ Nick Hesketh ~ Dave Encill |
  194. └───────────────────────────────────────────────────────────────────────┘
  195.  
  196. --
  197.  
  198.  
  199.